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Abstract 
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Les 


Introduction 


Since its early years, attendance at Internet Engineering Task Force 
(IETF) face-to-face meetings has grown phenomenally. Many of the 
attendees are new to the IETF at each meeting, and many of those go 
on to become regular attendees. When the meetings were smaller, it 
was relatively easy for a newcomer to get into the swing of things. 
Today, however, a newcomer meets many more new people, some 
previously known only as the authors of documents or thought- 
provoking email messages. 


This document describes many aspects of the IETF, with the goal of 
explaining to newcomers how the IETF works. This will give them a 
warm, fuzzy feeling and enable them to make the meeting and the 
Working Group discussions more productive for everyone. 


Of course, it’s true that many IETF participants don’t go to the 
face-to-face meetings at all. Instead, they’re active on the mailing 
list of various IETF Working Groups. Since the inner workings of 
Working Groups can be hard for newcomers to understand, this document 
provides the mundane bits of information that newcomers will need in 
order to become active participants. 


The IETF is always in a state of change. Although the principles in 
this document are expected to remain largely the same over time, 
practical details may well have changed by the time you read it; for 
example, a web-based tool may have replaced an email address for 
requesting some sort of action. 


Many types of IETF documentation are mentioned in the Tao, from BCPs 


to RFCs and FYIs and STDs. BCPs make recommendations for Best 
Current Practices in the Internet; RFCs are the IETF’s main technical 
documentation series, politely known as "Requests for Comments"; FYIs 


provide topical and technical overviews that are introductory or 
appeal to a broad audience; and STDs are RFCs identified as 
"standards". See Section 8 for more information. 


The acronyms and abbreviations used in this document are usually 
expanded in place and are explained fully in Appendix A. 


This document is intended to obsolete FYI 17, RFC 3160. See Section 
3.2.5 for information on what it means for one RFC to obsolete 
another. 
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What Is the IETF? 


The Internet Engineering Task Force is a loosely self-organized group 
of people who contribute to the engineering and evolution of Internet 
technologies. It is the principal body engaged in the development of 
new Internet standard specifications. The IETF is unusual in that it 
exists as a collection of happenings, but is not a corporation and 
has no board of directors, no members, and no dues; see [BCP95], "A 
Mission Statement for the IETF", for more detail. 


Its mission includes the following: 


o Identifying, and proposing solutions to, pressing operational and 
technical problems in the Internet 


o Specifying the development or usage of protocols and the near-term 
architecture to solve such technical problems for the Internet 


o Making recommendations to the Internet Engineering Steering Group 
(IESG) regarding the standardization of protocols and protocol 
usage in the Internet 


o Facilitating technology transfer from the Internet Research Task 
Force (IRTF) to the wider Internet community 


o Providing a forum for the exchange of information within the 
Internet community between vendors, users, researchers, agency 
contractors, and network managers 


The IETF meeting is not a conference, although there are technical 
presentations. The IETF is not a traditional standards organization, 
although many specifications are produced that become standards. The 
IETF is made up of volunteers, many of whom meet three times a year 
to fulfill the IETF mission. 
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There is no membership in the IETF. Anyone may register for and 
attend any meeting. The closest thing there is to being an IETF 
member is being on the IETF or Working Group mailing lists (see 
Section 3.3). This is where the best information about current IETF 
activities and focus can be found. 


Of course, no organization can be as successful as the IETF is 
without having some sort of structure. In the IETF’s case, that 
structure is provided by other organizations, as described in 
[BCP11], "The Organizations Involved in the IETF Standards Process". 
If you participate in the IETF and read only one BCP, this is the one 
you should read. 


In many ways, the IETF runs on the beliefs of its members. One of 
the "founding beliefs" is embodied in an early quote about the IETF 
from David Clark: "We reject kings, presidents and voting. We 
believe in rough consensus and running code". Another early quote 
that has become a commonly-held belief in the IETF comes from Jon 
Postel: "Be conservative in what you send and liberal in what you 
accept". 


The IETF is really about its members. Because of the unrestrictive 
membership policies, IETF members come from all over the world and 
from many different parts of the Internet industry. See Section 4.11 
for information about the ways that many people fit into the IETF. 


One more thing that is important for newcomers: the IETF in no way 
"runs the Internet", despite what some people mistakenly might say. 
The IETF makes standards that are often adopted by Internet users, 
but it does not control, or even patrol, the Internet. If your 
interest in the IETF is because you want to be part of the overseers, 
you may be badly disappointed by the IETF. 


3.1. Humble Beginnings 


The first IETF meeting was held in January 1986 at Linkabit in San 
Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in 
October 1986, was the first that non-government vendors attended. 

The concept of Working Groups was introduced at the 5th IETF meeting 
at the NASA Ames Research Center in California in February 1987. The 
7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the 
first meeting with more than 100 attendees. 
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The 14th IETF meeting was held at Stanford University in July 1989. 
It marked a major change in the structure of the IETF universe. The 
IAB (then Internet Activities Board, now Internet Architecture 
Board), which until that time oversaw many "task forces", changed its 
structure to leave only two: the IETF and the IRTF. The IRTF is 
tasked to consider long-term research problems in the Internet. The 
IETF also changed at that time. 


After the Internet Society (ISOC) was formed in January 1992, the IAB 
proposed to ISOC that the IAB's activities should take place under 
the auspices of the Internet Society. During INET92 in Kobe, Japan, 
the ISOC Trustees approved a new charter for the IAB to reflect the 
proposed relationship. 


The IETF met in Amsterdam, The Netherlands, in July 1993. This was 
the first IETF meeting held in Europe, and the US/non-US attendee 
split was nearly 50/50. About one in three IETF meetings are now 
held in Europe or Asia, and the number of non-US attendees continues 
to be high -- about 50%, even at meetings held in the United States. 


3.2. The Hierarchy 
3.2.1. ISOC (Internet Society) 


The Internet Society is an international, non-profit, membership 
organization that fosters the expansion of the Internet. One of the 
ways that ISOC does this is through financial and legal support of 
the other "I" groups described here, particularly the IETF. ISOC 
provides insurance coverage for many of the people in the IETF 
process and acts as a public relations channel for the times that one 
of the "I" groups wants to say something to the press. The ISOC is 
one of the major unsung (and under-supported) heroes of the Internet. 


Starting in spring 2005, the ISOC also became home base for the 
IETF’s directly employed administrative staff. This is described in 
more detail in [BCP101], "Structure of the IETF Administrative 
Support Activity (IASA)". The staff initially includes only an 
Administrative Director (IAD) who works full-time overseeing IETF 
meeting planning, operational aspects of support services (the 
secretariat, IANA (the Internet Assigned Numbers Authority), and the 
RFC Editor, which are described later in this section), and the 
budget. He or she (currently it’s a he) leads the IETF 
Administrative Support Activity (IASA), which takes care of tasks 
such as collecting meeting fees and paying invoices, and also 
supports the tools for the work of IETF working groups, the IESG, the 
IAB, and the IRTF (more about these later in this section). 
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As well as staff, the IASA comprises volunteers and ex officio 
members from the ISOC and IETF leadership. The IASA and the IAD are 
directed by the IETF Administrative Oversight Committee (IAOC), which 
is selected by the IETF community. Here's how all this looks: 


Internet Society 


IAOC 


IASA 


IAD 


Neither the IAD nor the IAOC have any influence over IETF standards 
development, which we turn to now. 


3.2.2. IESG (Internet Engineering Steering Group) 


The IESG is responsible for technical management of IETF activities 
and the Internet standards process. It administers the process 
according to the rules and procedures that have been ratified by the 
ISOC Trustees. However, the IESG doesn’t do much direct leadership, 
such as the kind you will find in many other standards organizations. 
As its name suggests, its role is to set directions rather than to 
give orders. The IESG ratifies or corrects the output from the 
IETF’s Working Groups (WGs), gets WGs started and finished, and makes 
sure that non-WG drafts that are about to become RFCs are correct. 


The IESG consists of the Area Directors (ADs), who are selected by 
the Nominations Committee (which is usually called "the NomCom") and 
are appointed for two years. The process for choosing the members of 
the IESG is detailed in [BCP10], "IAB and IESG Selection, 
Confirmation, and Recall Process: Operation of the Nominating and 
Recall Committees". 


The current areas and abbreviations are shown below. 
Area Description 


Applications (APP) Protocols seen by user programs, such as 
email and the web 


General (GEN) Catch-all for WGs that don’t fit in other 
areas (which is very few) 


Internet (INT) Different ways of moving IP packets and 
DNS information 


Hoffman & Harris Informational [Page 8] 


RFC 4677 The Tao of IETF September 2006 


Operations and Operational aspects, network monitoring, 
Management (OPS) and configuration 

Real-time Delay-sensitive interpersonal 
Applications and communications 


Infrastructure (RAI) 


Routing (RTG) Getting packets to their destinations 
Security (SEC) Authentication and privacy 
Transport (TSV) Special services for special packets 


Because the IESG has a great deal of influence on whether Internet 
Drafts become RFCs, many people look at the ADs as somewhat godlike 
creatures. IETF participants sometimes reverently ask Area Directors 
for their opinion on a particular subject. However, most ADs are 
nearly indistinguishable from mere mortals and rarely speak from 
mountaintops. In fact, when asked for specific technical comments, 
the ADs may often defer to members at large whom they feel have more 
knowledge than they do in that area. 


The ADs for a particular area are expected to know more about the 
combined work of the WGs in that area than anyone else. On the other 
hand, the entire IESG reviews each Internet Draft that is proposed to 
become an RFC. Any AD may record a "DISCUSS" ballot position against 
a draft if he or she has serious concerns. If these concerns cannot 
be resolved by discussion, an override procedure is defined such that 
at least two IESG members must express concerns before a draft can be 
blocked from moving forward. These procedures help ensure that an 
AD’s "pet project" doesn’t make it onto the standards track if it 
will have a negative effect on the rest of the IETF protocols and 
that an AD’s "pet peeve" cannot indefinitely block something. 


This is not to say that the IESG never wields power. When the IESG 
sees a Working Group veering from its charter, or when a WG asks the 
IESG to make the WG’s badly designed protocol a standard, the IESG 
will act. In fact, because of its high workload, the IESG usually 
moves in a reactive fashion. It eventually approves most WG requests 
for Internet Drafts to become RFCs, and usually only steps in when 
something has gone very wrong. Another way to think about this is 
that the ADs are selected to think, not to just run the process. The 
quality of the IETF standards comes both from the review they get in 
the Working Groups and the scrutiny that the WG review gets from the 
ADs. 
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The IETF is run by rough consensus, and it is the IESG that judges 
whether a WG has come up with a result that has community consensus. 
(See Section 5.2 for more information on WG consensus.) Because of 
this, one of the main reasons that the IESG might block something 
that was produced in a WG is that the result did not really gain 
consensus in the IETF as a whole, that is, among all of the Working 
Groups in all areas. For instance, the result of one WG might clash 
with a technology developed in a different Working Group. An 
important job of the IESG is to watch over the output of all the WGs 
to help prevent IETF protocols that are at odds with each other. 
This is why ADs are supposed to review the drafts coming out of areas 
other than their own. 


3.2.3. IAB (Internet Architecture Board) 


The IAB is responsible for keeping an eye on the "big picture" of the 
Internet, and it focuses on long-range planning and coordination 
among the various areas of IETF activity. The IAB stays informed 
about important long-term issues in the Internet, and it brings these 
topics to the attention of people it thinks should know about them. 
The IAB web site is at http://www.iab.org/. 


IAB members pay special attention to emerging activities in the IETF. 
When a new IETF Working Group is proposed, the IAB reviews its 
charter for architectural consistency and integrity. Even before the 
group is chartered, the IAB members are more than willing to discuss 
new ideas with the people proposing them. 


The IAB also sponsors and organizes the Internet Research Task Force 
and convenes invitational workshops that provide in-depth reviews of 
specific Internet architectural issues. Typically, the workshop 
reports make recommendations to the IETF community and to the IESG. 
The IAB also: 

o Approves NomCom’s IESG nominations 

o Acts as the appeals board for appeals against IESG actions 

o Appoints and oversees the RFC Editor 

o Approves the appointment of the IANA 


o Acts as an advisory body to ISOC 


o Oversees IETF liaisons with other standards bodies 
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Like the IESG, the IAB members are selected for multi-year positions 
by the NomCom and are approved by the ISOC Board of Trustees. 


3.2.4. IANA (Internet Assigned Numbers Authority) 


The core registrar for the IETF’s activities is the IANA. Many 
Internet protocols require that someone keep track of protocol items 
that were added after the protocol came out. Typical examples of the 
kinds of registries needed are for TCP port numbers and MIME types. 
The IAB has designated the IANA organization to perform these tasks, 
and the IANA’s activities are financially supported by ICANN, the 
Internet Corporation for Assigned Names and Numbers. 


Ten years ago, no one would have expected to see the IANA mentioned 
on the front page of a newspaper. IANA’s role had always been very 
low key. The fact that IANA was also the keeper of the root of the 
domain name system forced it to become a much more public entity, one 
that was badly maligned by a variety of people who never looked at 
what its role was. Nowadays, the IETF is generally no longer 
involved in the IANA’s domain name and IP address assignment 
functions, which are overseen by ICANN. 


Even though being a registrar may not sound interesting, many IETF 
participants will testify to how important IANA has been for the 
Internet. Having a stable, long-term repository run by careful and 
conservative operators makes it much easier for people to experiment 
without worrying about messing things up. IANA’s founder, Jon 
Postel, was heavily relied upon to keep things in order while the 
Internet kept growing by leaps and bounds, and he did a fine job of 
it until his untimely death in 1998. 


3.2.5. RFC Editor 


The RFC Editor edits, formats, and publishes Internet Drafts as RFCs, 
working in conjunction with the IESG. An important secondary role is 
to provide one definitive repository for all RFCs (see 
http://www.rfc-editor.org). Once an RFC is published, it is never 
revised. If the standard it describes changes, the standard will be 
re-published in another RFC that "obsoletes" the first. 


One of the most popular misconceptions in the IETF community is that 
the role of the RFC Editor is performed by IANA. In fact, the RFC 
Editor is a separate job, although both the RFC Editor and IANA 
involved the same people for many years. The IAB approves the 
organization that will act as RFC Editor and the RFC Editor’s general 
policy. The RFC Editor is funded by IASA and can be contacted by 
email at mailto:rfc-editor@rfc-editor.org. 
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3.2.6. IETF Secretariat 


There are, in fact, a few people who are paid to maintain the IETF. 
The IETF Secretariat provides day-to-day logistical support, which 
mainly means coordinating face-to-face meetings and running the 
IETF-specific mailing lists (not the WG mailing lists). The 
Secretariat is also responsible for keeping the official Internet 
Drafts directory up to date and orderly, maintaining the IETF web 
site, and helping the IESG do its work. It provides various tools 
for use by the community and the IESG. The IETF Secretariat is under 
contract to IASA, which in turn is financially supported by the fees 
of the face-to-face meetings. 


3.3. IETF Mailing Lists 


Anyone who plans to attend an IETF meeting should join the IETF 
announcement mailing list, mailto:ietf-announce@ietf.org. This is 
where all of the meeting information, RFC announcements, and IESG 
Protocol Actions and Last Calls are posted. People who would like to 
"get technical" may also join the IETF general discussion list, 
ietf@ietf.org. This is where discussions of cosmic significance are 
held (Working Groups have their own mailing lists for discussions 
related to their work). Another mailing list, mailto:i-d- 
announce@ietf.org, announces each new version of every Internet Draft 
as it is published. 


Subscriptions to these and other IETF-run mailing lists are handled 
by a program called "mailman". Mailman can be somewhat finicky about 
the format of subscription messages, and sometimes interacts poorly 
with email programs that make all email messages into HTML files. 
Mailman will treat you well, however, if you format your messages 
just the way it likes. 


To join the IETF announcement list, for example, send email to 
mailto:ietf-announce-request@ietf.org. Enter the word ’subscribe’ 
(without the quotes) in the Subject line of the message and in the 
message body. To join the IETF discussion list, send email to 
<mailto:ietf-request@ietf.org> and enter the word ’subscribe’ as 
explained above. If you decide to withdraw from either list, use the 
word 'unsubscribe”. Your messages to mailman should have nothing 
other than the commands 'subscribe” or 'unsubscribe” in them. Both 
lists are archived on the IETF web site, 
http://www.ietf.org/maillist-.html. 
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Do not, ever, under any circumstances, for any reason, send a request 
to join a list to the list itself! The thousands of people on the 
list don’t need, or want, to know when a new person joins. 

Similarly, when changing email addresses or leaving a list, send your 
request only to the "-request" address, not to the main list. This 
means you!! 


The IETF discussion list is unmoderated. This means that all can 


express their opinions about issues affecting the Internet. However, 
it is not a place for companies or individuals to solicit or 
advertise, as noted in [BCP45], “IETF Discussion List Charter". It 


is a good idea to read the whole RFC (it’s short!) before posting to 
the IETF discussion list. Actually, the list does have two 
"sergeants at arms" who keep an eye open for inappropriate postings, 
and there is a process for banning persistent offenders from the 
list, but fortunately this is extremely rare. 


Only the Secretariat and certain IETF office holders can approve 
messages sent to the announcement list, although those messages can 
come from a variety of people. 


Even though the IETF mailing lists "represent" the IETF membership at 
large, it is important to note that attending an IETF meeting does 
not mean you’ll be automatically added to either mailing list. 


4. IETF Meetings 


The computer industry is rife with conferences, seminars, 
expositions, and all manner of other kinds of meetings. IETF face- 
to-face meetings are nothing like these. The meetings, held three 
times a year, are week-long "gatherings of the tribes" whose primary 
goal is to reinvigorate the WGs to get their tasks done, and whose 
secondary goal is to promote a fair amount of mixing between the WGs 
and the areas. The cost of the meetings is paid by the people 
attending and by the corporate host for each meeting (if any), 
although IASA kicks in additional funds for things such as the audio 
broadcast of some Working Group sessions. 


For many people, IETF meetings are a breath of fresh air when 
compared to the standard computer industry conferences. There is no 
exposition hall, few tutorials, and no big-name industry pundits. 
Instead, there is lots of work, as well as a fair amount of time for 
socializing. IETF meetings are of little interest to sales and 
marketing folks, but of high interest to engineers and developers. 


Most IETF meetings are held in North America, because that’s where 


most of the participants are from; however, meetings are held on 
other continents about once every year. The past few meetings have 
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had about 1,300 attendees. There have been more than 65 IETF 
meetings so far, and a list of upcoming meetings is available on the 
IETF web pages, http://www.ietf.org/meetings/Omtg-sites.txt. 


Newcomers to IETF face-to-face meetings are often in a bit of shock. 
They expect them to be like other standards bodies, or like computer 
conferences. Fortunately, the shock wears off after a day or two, 
and many new attendees get quite animated about how much fun they are 
having. One particularly jarring feature of recent IETF meetings is 
the use of wireless Internet connections throughout the meeting 
space. It is common to see people in a WG meeting apparently reading 
email or perusing the web during presentations they find 
uninteresting. Remember, however, that they may also be consulting 
the drafts under discussion, looking up relevant material online, or 
following another meeting using instant messaging. 


4.1. Registration 


To attend an IETF meeting, you have to register and you have to pay 
the registration fee. The meeting site and advance registration are 
announced about two months ahead of the meeting -- earlier if 
possible. An announcement goes out via email to the IETF-announce 
mailing list, and information is posted on the IETF web site, 
http://www.ietf.org, that same day. 


To pre-register, you must submit your registration on the web. You 
may pre-register and pre-pay, pre-register and return to the web site 
later to pay with a credit card, pre-register and pay on-site at the 
meeting, or register and pay on-site. To get a lower registration 
fee, you must pay by the early registration deadline (about one week 
before the meeting). The registration fee covers all of the week’s 
meetings, the Sunday evening reception (cash bar), daily continental 
breakfasts, and afternoon coffee and snack breaks. 


Credit card payments on the web are encrypted and secure, or, if you 
prefer, you can use Pretty Good Privacy (PGP) to send your payment 
information to the Registrar (mailto:ietf-registrar@ietf.org). 


Registration is open throughout the week of the meeting. However, 
the Secretariat highly recommends that attendees arrive for early 
registration, usually beginning at noon on Sunday and continuing 
throughout the Sunday evening reception. The reception is a popular 
event where you can get a small bite to eat and socialize with other 
early arrivals. 


Registered attendees (and there aren't any other kind) receive a 
registration packet. It contains much useful information, including 
a general orientation sheet, the most recent agenda, and a name tag. 
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Attendees who pre-paid will also find their receipt in their packet. 
It’s worth noting that neither attendee names and addresses nor IETF 
mailing lists are ever offered for sale. 


In your registration packet is a sheet titled "Note Well". You 
should indeed read it carefully because it lays out the rules for 
IETF intellectual property rights. 


If you need to leave messages for other attendees, you can do so at 
the cork boards that are often near the registration desk. These 
cork boards will also have last-minute meeting changes and room 
changes. 


You can also turn in lost-and-found items to the registration desk. 
At the end of the meeting, anything left over from the lost and found 
will usually be turned over to the hotel or brought back to the 
Secretariat’s office. 


Incidentally, the IETF registration desk is often a convenient place 
to arrange to meet people. If someone says "meet me at 
registration", they almost always mean the IETF registration desk, 
not the hotel registration desk. 


4.2. Take the Plunge and Stay All Week! 


IETF meetings last from Monday morning through Friday lunchtime. 
Associated meetings often take place on the preceding or following 
weekends. It is best to plan to be present the whole week, to 
benefit from cross-fertilization between Working Groups and from 
corridor discussions. As noted below, the agenda is fluid, and there 
have been many instances of participants missing important sessions 
due to last-minute scheduling changes after their travel plans were 
fixed. Being present the whole week is the only way to avoid this 
annoyance. 


If you cannot find meetings all week to interest you, you can still 
make the most of the IETF meeting by working between sessions. Most 
IETF attendees carry laptop computers, and it is common to see many 
of them in the terminal room or in the hallways working during 
meeting sessions. There is often good wireless Internet coverage in 
many places of the meeting venue (restaurants, coffee shops, and so 
on), so catching up on email when not in meetings is a fairly common 
task for IETFers. 
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4.3. Newcomer Training 


Newcomers are encouraged to attend the Newcomer Training, which is 
especially designed for first-time attendees. The orientation is 
organized and conducted by the IETF EDU team and is intended to 
provide useful introductory information. The session covers what’s 
in the attendee packets, what all the dots on name tags mean, the 
structure of the IETF, and many other essential and enlightening 
topics for new IETFers. 


Immediately following the Newcomers’ Training is the IETF Standards 
Process Orientation. This session demystifies much of the standards 
process by explaining what stages a document has to pass through on 
its way to becoming a standard, and what has to be done to advance to 
the next stage. 


There is usually ample time at the end for questions. The 
Secretariat provides hard copies of the slides of the "IETF Structure 
and Internet Standards Process" presentation -- these very useful 
slides are also available online at www.ietf.org under "Educational 
Materials". 


The orientation is normally held on Sunday afternoon, along with 
tutorials of interest to newcomers and old-timers alike. Check the 
agenda for exact times and locations. 


4.4. Dress Code 


Since attendees must wear their name tags, they must also wear shirts 
or blouses. Pants or skirts are also highly recommended. Seriously 
though, many newcomers are often embarrassed when they show up Monday 
morning in suits, to discover that everybody else is wearing T- 
shirts, jeans (shorts, if weather permits) and sandals. There are 
those in the IETF who refuse to wear anything other than suits. 
Fortunately, they are well known (for other reasons) so they are 
forgiven this particular idiosyncrasy. The general rule is "dress 
for the weather" (unless you plan to work so hard that you won’t go 
outside, in which case, "dress for comfort" is the rule!). 


4.5. Seeing Spots Before Your Eyes 
Some of the people at the IETF will have a little colored dot on 
their name tag. A few people have more than one. These dots 


identify people who are silly enough to volunteer to do a lot of 
extra work. The colors have the meanings shown here. 
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Color Meaning 

Blue Working Group/BOF chair 
Green Host group 

Red IAB member 

Yellow IESG member 

Orange Nominating Committee member 


(Members of the press wear orange-tinted badges.) 


Local hosts are the people who can answer questions about the 
terminal room, restaurants, and points of interest in the area. 


It is important that newcomers to the IETF not be afraid to strike up 
conversations with people who wear these dots. If the IAB and IESG 
members and Working Group and BOF chairs didn’t want to talk to 
anybody, they wouldn’t be wearing the dots in the first place. 


4.6. Terminal Room 


One of the most important (depending on your point of view) things 
the host does is provide Internet access for the meeting attendees. 
In general, wired and wireless connectivity is excellent. This is 
entirely due to the Olympian efforts of the local hosts and their 
ability to beg, borrow, and steal. The people and companies that 
donate their equipment, services, and time are to be heartily 
congratulated and thanked. 


Although preparation far in advance of the meeting is encouraged, 
there may be some unavoidable "last minute" things that can be 
accomplished in the terminal room. It may also be useful to people 
who need to make trip reports or status reports while things are 
still fresh in their minds. 


You need to be wearing your badge in order to get into the terminal 
room. The terminal room provides lots of power strips, lots of 
Ethernet ports for laptops, wireless (for the people who don’t need 
Ethernet but want power), usually a printer for public use, and 
sometimes workstations. What it doesn’t provide are terminals; the 
name is historical. The help desk in the terminal room is a good 
place to ask questions about network failures, although they might 
point you off to different networking staff. 


4.7. Meals and Other Delights 
Marshall Rose once remarked that the IETF was a place to go for "many 


fine lunches and dinners". Although it is true that some people eat 
very well at the IETF, they find the food on their own; lunches and 


Hoffman & Harris Informational [Page 17] 


RFC 4677 The Tao of IETF September 2006 


dinners are not included in the registration fee. The Secretariat 
does provide appetizers at the Sunday evening reception (not meant to 
be a replacement for dinner), continental breakfast every morning, 
and (best of all) cookies, brownies, and other yummies during 
afternoon breaks. 


If you prefer to get out of the hotel for meals, the local host 
usually provides a list of places to eat within easy reach of the 
meeting site. 


4.8. Social Event 


Another of the most important things organized and managed by the 
host is the IETF social event. Sometimes, the social event is a 
computer- or high-tech-related event. At one Boston IETF, for 
example, the social was dinner at the Computer Museum. Other times, 
the social might be a dinner cruise or a trip to an art gallery. 
Note, however, that not all IETF meetings have social events. 


Newcomers to the IETF are encouraged to attend the social event. All 
are encouraged to wear their name tags and leave their laptops 
behind. The social event is designed to give people a chance to meet 
on a social, rather than technical, level. 


4.9. Agenda 


The agenda for the IETF meetings is a very fluid thing. It is 
typically sent to the IETF announcement list a few times prior to the 
meeting, and it is also available on the web. The final agenda is 
included in the registration packets. Of course, "final" in the IETF 
doesn’t mean the same thing as it does elsewhere in the world. The 
final agenda is simply the version that went to the printer. The 
Secretariat will post agenda changes on the bulletin board near the 


IETF registration desk (not the hotel registration desk). These late 
changes are not capricious: they are made "just in time" as session 
chairs and speakers become aware of unanticipated clashes. The IETF 


is too dynamic for agendas to be tied down weeks in advance. 


Assignments for breakout rooms (where the Working Groups and BOFs 
meet) and a map showing the room locations are also shown on the 
agenda. Room assignments can change as the agenda changes. Some 
Working Groups meet multiple times during a meeting, and every 
attempt is made to have a Working Group meet in the same room for 
each session. 


Hoffman & Harris Informational [Page 18] 


RFC 4677 The Tao of IETF September 2006 


4. 


4. 


4. 


10. EDU to the Rescue 


If certain aspects of the IETF still mystify you (even after you 
finish reading the Tao), you'll want to drop in on the on-site 
training offered by the Education (EDU) team. These informal classes 
are designed for newcomers and seasoned IETFers alike. In addition 
to the Newcomer Training, the EDU team offers workshops for document 
editors and Working Group chairs, plus an in-depth security tutorial 
that’s indispensable for both novices and longtime IETF attendees. 
EDU sessions are generally held on Sunday afternoons. You'll find 
more about the EDU team at http://edu.ietf.org/. 


11. Where Do I Fit In? 


The IETF is different things to different people. There are many 
people who have been very active in the IETF who have never attended 
an IETF meeting. You should not feel obligated to come to an IETF 
meeting just to get a feel for the IETF. The following guidelines 
(based on stereotypes of people in various industries) might help you 
decide whether you actually want to come and, if so, what might be 
the best use of your time at your first meeting. 


11.1. IS Managers 


As discussed throughout this document, an IETF meeting is nothing 
like any trade show you have attended. IETF meetings are singularly 
bad places to go if your intention is to find out what will be hot in 
the Internet industry next year. You can safely assume that going to 
Working Group meetings will confuse you more than it will help you 
understand what is happening, or will be happening, in the industry. 


This is not to say that no one from the industry should go to IETF 
meetings. As an IS manager, you might want to consider sending 
specific people who are responsible for technologies that are under 
development in the IETF. As these people read the current Internet 
Drafts and the traffic on the relevant Working Group lists, they will 
get a sense of whether or not their presence would be worthwhile for 
your company or for the Working Groups. 


4.11.2. Network Operators and ISPs 


Running a network is hard enough without having to grapple with new 
protocols or new versions of the protocols with which you are already 
dealing. If you work for the type of network that is always using 
the very latest hardware and software, and you are following the 
relevant Working Groups in your copious free time, you could 
certainly find participating in the IETF valuable. A fair amount of 
IETF work also covers many other parts of operations of ISPs and 
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large enterprises, and the input of operators is quite valuable to 
keep this work vibrant and relevant. Many of the best operations 
documents from the IETF come from real-world operators, not vendors 
and academics. 


4.11.3. Networking Hardware and Software Vendors 


The image of the IETF being mostly ivory tower academics may have 
been true in the past, but the jobs of typical attendees are now in 
industry. In most areas of the IETF, employees of vendors are the 
ones writing the protocols and leading the Working Groups, so it’s 
completely appropriate for vendors to attend. If you create Internet 
hardware or software, and no one from your company has ever attended 
an IETF meeting, it behooves you to come to a meeting if for no other 
reason than to tell the others how relevant the meeting was or was 
not to your business. 


This is not to say that companies should close up shop during IETF 
meeting weeks so everyone can go to the meeting. Marketing folks, 
even technical marketing folks, are usually safe in staying away from 
the IETF as long as some of the technical people from the company are 
at the meeting. Similarly, it isn’t required, or likely useful, for 
everyone from a technical department to go, particularly if they are 
not all reading the Internet Drafts and following the Working Group 
mailing lists. Many companies have just a few designated meeting 
attendees who are chosen for their ability to do complete and useful 
trip reports. In addition, many companies have internal coordination 
efforts and a standards strategy. If a company depends on the 
Internet for some or all of its business, the strategy should 
probably cover the IETF. 


4.11.4. Academics 


IETF meetings are often excellent places for computer science folks 
to find out what is happening in the way of soon-to-be-deployed 
protocols. Professors and grad students (and sometimes overachieving 
undergrads) who are doing research in networking or communications 
can get a wealth of information by following Working Groups in their 
specific fields of interest. Wandering into different Working Group 
meetings can have the same effect as going to symposia and seminars 
in your department. Researchers are also, of course, likely to be 
interested in IRTF activities. 


4.11.5. Computer Trade Press 
If you’re a member of the press and are considering attending IETF, 


we've prepared a special section of the Tao just for you -- please 
see Section 10.2. 
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4.12. Proceedings 


IETF proceedings are compiled in the two months following each 
meeting and are available on the web and on CD. Be sure to look 
through a copy -- the proceedings are filled with information about 
IETF that you’re not likely to find anywhere else. For example, 
you'll find snapshots of most WG charters at the time of the meeting, 
giving you a better understanding of the evolution of any given 
effort. 


The proceedings sometimes start with an informative (and highly 
entertaining) message. Each volume contains the final (hindsight) 
agenda, an IETF overview, area and Working Group reports, and slides 
from the protocol and technical presentations. The Working Group 
reports and presentations are sometimes incomplete, if the materials 
haven’t been turned in to the Secretariat in time for publication. 


An attendee list is also included, which contains names and 
affiliations as provided on the registration form. For information 
about obtaining copies of the proceedings, see the web listing at 
http://www.ietf.org/proceedings/directory.html. 


4.13. Other General Things 


The IETF Secretariat, and IETFers in general, are very approachable. 
Never be afraid to approach someone and introduce yourself. Also, 
don’t be afraid to ask questions, especially when it comes to jargon 
and acronyms. 


Hallway conversations are very important. A lot of very good work 
gets done by people who talk together between meetings and over 
lunches and dinners. Every minute of the IETF can be considered work 
time (much to some people’s dismay). 


A "bar BOF" is an unofficial get-together, usually in the late 
evening, during which a lot of work gets done over drinks. Bar BOFs 
spring up in many different places around an IETF meeting, such as 
restaurants, coffee shops, and (if we are so lucky) pools. 


It’s unwise to get between a hungry IETFer (and there isn’t any other 
kind) and coffee break brownies and cookies, no matter how 
interesting a hallway conversation is. 


IETFers are fiercely independent. It’s safe to question opinions and 
offer alternatives, but don’t expect an IETFer to follow orders. 
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The IETF meetings, and the plenary session in particular, are not 
places for vendors to try to sell their wares. People can certainly 
answer questions about their company and its products, but bear in 
mind that the IETF is not a trade show. This does not preclude 
people from recouping costs for IETF-related T-shirts, buttons, and 
pocket protectors. 


There is always a "materials distribution table" near the 
registration desk. This desk is used to make appropriate information 
available to the attendees (e.g., copies of something discussed in a 
Working Group session, descriptions of online IETF-related 
information). Please check with the Secretariat before placing 
materials on the desk; the Secretariat has the right to remove 
material that he or she feels is not appropriate. 


If you rely on your laptop during the meeting, it is a good idea to 
bring an extra battery. It is not always easy to find a spare outlet 
in some meeting rooms, and using the wireless access can draw down 
your battery faster than you might expect. If you are sitting near a 
power-strip in a meeting room, expect to be asked to plug and unplug 
for others around you. Many people bring an extension cord with 
spare outlets, which is a good way to make friends with your neighbor 
in a meeting. If you need an outlet adapter, you should try to buy 
it in advance because the one you need is usually easier to find in 
your home country. 


5. Working Groups 


The vast majority of the IETF’s work is done in many Working Groups; 


at the time of this writing, there are about 115 different WGs. (The 
term "Working Group" is often seen capitalized, but probably not for 
any good reason.) [BCP25], "IETF Working Group Guidelines and 
Procedures", is an excellent resource for anyone participating in WG 
discussions. 


A WG is really just a mailing list with a bit of adult supervision. 
You "join" the WG by subscribing to the mailing list; all mailing 
lists are open to anyone. Anyone can post to a WG mailing list, 
although most lists require non-subscribers to have their postings 
moderated. Each Working Group has one or two chairs. 


More important, each WG has a charter that the WG is supposed to 
follow. The charter states the scope of discussion for the Working 
Group, as well as its goals. The WG’s mailing list and face-to-face 
meetings are supposed to focus on just what is in the charter and not 
to wander off on other "interesting" topics. Of course, looking a 
bit outside the scope of the WG is occasionally useful, but the large 
majority of the discussion should be on the topics listed in the 
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charter. In fact, some WG charters actually specify what the WG will 
not do, particularly if there were some attractive but nebulous 
topics brought up during the drafting of the charter. The list of 
all WG charters makes interesting reading for folks who want to know 
what the different Working Groups are supposed to be doing. 


5.1. Working Group Chairs 


The role of the WG chairs is described in both [BCP11] and [BCP25]. 
The IETF EDU team also offers special training for WG chairs on 
Sunday afternoons preceding IETF. 


As volunteer cat-herders, a chair’s first job is to determine the WG 
consensus goals and milestones, keeping the charter up to date. 

Next, often with the help of WG secretaries or document editors, the 
chair must manage WG discussion, both on the list and by scheduling 
meetings when appropriate. Sometimes discussions get stuck on 
contentious points and the chair may need to steer people toward 
productive interaction and then declare when rough consensus has been 
met and the discussion is over. Sometimes chairs also manage 
interactions with non-WG participants or the IESG, especially when a 
WG document approaches publication. Chairs have responsibility for 
the technical and non-technical quality of WG output. As you can 
imagine given the mix of secretarial, interpersonal, and technical 
demands, some Working Group chairs are much better at their jobs than 
others. 


When a WG has fulfilled its charter, it is supposed to cease 
operations. (Most WG mailing lists continue on after a WG is closed, 
still discussing the same topics as the Working Group did.) In the 
IETF, it is a mark of success that the WG closes up because it 
fulfilled its charter. This is one of the aspects of the IETF that 
newcomers who have experience with other standards bodies have a hard 
time understanding. However, some WG chairs never manage to get 
their WG to finish, or keep adding new tasks to the charter so that 
the Working Group drags on for many years. The output of these aging 
WGs is often not nearly as useful as the earlier products, and the 
messy results are sometimes attributed to what’s called "degenerative 
Working Group syndrome". 


There is an official distinction between WG drafts and independent 
drafts, but in practice, sometimes there is not much procedural 
difference. For example, many WG mailing lists also discuss 


independent drafts (at the discretion of the WG chair). Procedures 
for Internet Drafts are covered in much more detail later in this 
document. 
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WG chairs are strongly advised to go to the WG leadership training 
that usually happens on the Sunday preceding the IETF meeting. There 
is also usually a WG chairs lunch mid-week during the meeting where 
chair-specific topics are presented and discussed. If you're 
interested in what they hear there, take a look at the slides at 
http://edu.ietf.org/. 


5.2. Getting Things Done in a Working Group 


One fact that confuses many novices is that the face-to-face WG 
meetings are much less important in the IETF than they are in most 
other organizations. Any decision made at a face-to-face meeting 
must also gain consensus on the WG mailing list. There are numerous 
examples of important decisions made in WG meetings that are later 
overturned on the mailing list, often because someone who couldn’t 
attend the meeting pointed out a serious flaw in the logic used to 
come to the decision. Finally, WG meetings aren’t "drafting 
sessions", as they are in some other standards bodies: in the IETF, 
drafting is done elsewhere. 


Another aspect of Working Groups that confounds many people is the 
fact that there is no formal voting. The general rule on disputed 
topics is that the Working Group has to come to "rough consensus", 


meaning that a very large majority of those who care must agree. The 
exact method of determining rough consensus varies from Working Group 
to Working Group. Sometimes consensus is determined by "humming" -- 


if you agree with a proposal, you hum when prompted by the chair; if 
you disagree, you keep your silence. Newcomers find it quite 
peculiar, but it works. It is up to the chair to decide when the 
Working Group has reached rough consensus. 


The lack of formal voting has caused some very long delays for some 
proposals, but most IETF participants who have witnessed rough 
consensus after acrimonious debates feel that the delays often result 
in better protocols. (And, if you think about it, how could you have 
"voting" in a group that anyone can join, and when it’s impossible to 
count the participants?) Rough consensus has been defined in many 
ways; a simple version is that it means that strongly held objections 
must be debated until most people are satisfied that these objections 
are wrong. 
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Some Working Groups have complex documents or a complex set of 
documents (or even both). Shaking all the bugs out of one or more 
complex documents is a daunting task. In order to help relieve this 
problem, some Working Groups use "issue trackers", which are online 
lists of the open issues with the documents, the status of the issue, 
proposed fixes, and so on. Using an issue tracker not only helps the 
WG not to forget to do something important, it helps when someone 
asks a question later about why something was done in a particular 
fashion. 


Another method that some Working Groups adopt is to have a Working 
Group "secretary" to handle the juggling of the documents and the 
changes. The secretary can run the issue tracker if there is one, or 
can simply be in charge of watching that all of the decisions that 
are made on the mailing list are reflected in newer versions of the 
documents. 


One thing you might find helpful, and possibly even entertaining, 
during Working Group sessions is to follow the running commentary on 
the Jabber room associated with that Working Group. The running 
commentary is often used as the basis for the minutes of the meeting, 
but it can also include jokes, sighs, and other extraneous chatter. 
Jabber is a free, streaming XML technology mainly used for instant 
messaging. You can find pointers to Jabber clients for many 
platforms at http://www.jabber.org. The Jabber chatrooms have the 
name of the Working Group followed by "@jabber.ietf.org". Those 
rooms are, in fact, available year-round, not just during IETF 
meetings, and some are used by active Working Group participants 
during protocol development. 


5.3. Preparing for Working Group Meetings 


The most important thing that everyone (newcomers and seasoned 
experts) should do before coming to a face-to-face meeting is to read 
the Internet Drafts and RFCs ahead of time. WG meetings are 
explicitly not for education: they are for developing the group’s 
documents. Even if you do not plan to say anything in the meeting, 
you should read the group’s documents before attending so you can 
understand what is being said. 


It’s up to the WG chair to set the meeting agenda, usually a few 
weeks in advance. If you want something discussed at the meeting, be 
sure to let the chair know about it. The agendas for all the WG 
meetings are available in advance (see 
http://www.ietf.org/meetings/wg_agenda_xx.html, where ’xx’ is the 
meeting number), but many WG chairs are lax (if not totally 
negligent) about turning them in. 
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The Secretariat only schedules WG meetings a few weeks in advance, 
and the schedule often changes as little as a week before the first 
day. If you are only coming for one WG meeting, you may have a hard 
time booking your flight with such little notice, particularly if the 
Working Group’s meeting changes schedule. Be sure to keep track of 
the current agenda so you can schedule flights and hotels. But, when 
it comes down to it, you probably shouldn’t be coming for just one WG 
meeting. It’s likely that your knowledge could be valuable in a few 
WGs, assuming that you’ve read the drafts and RFCs for those groups. 


If you are on the agenda at a face-to-face meeting, you should 
probably come with a few slides prepared. But don’t come with a 
tutorial; people are supposed to read the drafts in advance. 
Projectors for laptop-based presentations are available in all the 
meeting rooms. 


And here’s a tip for your slides in WG or plenary presentations: 
don’t put your company’s logo on every one, even though that is a 
common practice outside the IETF. The IETF frowns on this kind of 
corporate advertising (except for the meeting sponsor in the plenary 
presentation), and most presenters don’t even put their logo on their 
opening slide. The IETF is about technical content, not company 
boosterism. Slides are often plain black and white for legibility, 
with color used only when it really adds clarity. Again, the content 
is the most important part of the slides, not how it’s presented. 


5.4. Working Group Mailing Lists 


As we mentioned earlier, the IETF announcement and discussion mailing 


lists are the central mailing lists for IETF activities. However, 
there are many other mailing lists related to IETF work. For 
example, every Working Group has its own discussion list. In 


addition, there are some long-term technical debates that have been 
moved off of the IETF list onto lists created specifically for those 
topics. It is highly recommended that you follow the discussions on 
the mailing lists of the Working Groups that you wish to attend. The 
more work that is done on the mailing lists, the less work that will 
need to be done at the meeting, leaving time for cross pollination 
(i.e., attending Working Groups outside one's primary area of 
interest in order to broaden one’s perspective). 


The mailing lists also provide a forum for those who wish to follow, 
or contribute to, the Working Groups’ efforts, but can’t attend the 
IETF meetings. That’s why IETF procedures require all decisions to 
be confirmed "on the list" and you will often hear a WG chair say, 
"Let's take it to the list" to close a discussion. 


Hoffman & Harris Informational [Page 26] 


RFC 4677 The Tao of IETF September 2006 


Many IETF discussion lists use either mailman or another list 


manager, Majordomo. They usually have a "-request" address that 
handles the administrative details of joining and leaving the list. 
(See Section 3.3 for more information on mailman.) It is generally 


frowned upon when such administrivia appears on the discussion 
mailing list. 


Most IETF discussion lists are archived. That is, all of the 
messages sent to the list are automatically stored on a host for 
anonymous HTTP or FTP access. Many such archives are listed online 
at ftp://ftp.ietf.org/ietf-mail-archive/ or they are in a web-based 
archive. If you don't find the list you're looking for, send a 
message to the list's "-request" address (not to the list itself!). 
The Working Group charter listings at 

http: //www.ietf.org/html.charters/wg-dir.html are a useful source; 
note that the page has links to old, concluded WGs. 


Some WG lists apply size limits on messages, particularly to avoid 
large documents or presentations landing in everyone's mailbox. It 
is well worth remembering that participants do not all have broadband 
connections (and even those with broadband connections sometimes get 
their mail on slow connections when they travel), so shorter messages 
are greatly appreciated. Documents can be posted as Internet Drafts; 
presentation material can be posted to a web site controlled by the 
sender or sent personally to people who ask for it. Some WGs set up 
special sites to hold these large documents so that senders can post 
there first, then just send to the list the URL of the document. 


5.5. Interim Working Group Meetings 


Working Groups sometimes hold interim meetings between IETFs. 

Interim meetings aren't a substitute for IETF meetings, however -- a 
group can’t decide to skip a meeting in a location they’re not fond 
of and meet in Cancun (or even someplace mundane) three weeks later, 


for example. Interim meetings require AD approval and need to be 
announced at least one month in advance. Location and timing need to 
allow fair access for all participants. Like regular IETF meetings, 


someone needs to take notes and send them to 
mailto:proceedings@ietf.org, and the group needs to take attendance. 
Decisions tentatively made during an interim WG meeting still must be 
ratified on the mailing list. 


6. BOFs 


In order to form a Working Group, you need a charter and someone who 
is able to be chair. In order to get those things, you need to get 
people interested so that they can help focus the charter and 
convince an Area Director that the project is worthwhile. A face- 
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to-face meeting is useful for this. In fact, very few WGs get 
started by an Area Director; most start after a face-to-face BOF 
because attendees have expressed interest in the topic. 


A Birds of a Feather (BOF) meeting has to be approved by the Area 


Director in the relevant area before it can be scheduled. If you 
think you really need a new WG, approach an AD informally with your 
proposal and see what he or she thinks. The next step is to request 


a meeting slot at the next face-to-face meeting. Of course, you 
don’t need to wait for that meeting to get some work done, such as 
setting up a mailing list and starting to discuss a charter. 


BOF meetings have a very different tone than do WG meetings. The 
purpose of a BOF is to make sure that a good charter with good 
milestones can be created and that there are enough people willing to 


do the work needed in order to create standards. Some BOFs have 
Internet Drafts already in process, whereas others start from 
scratch. 


An advantage of having a draft before the BOF is to help focus the 
discussion. On the other hand, having a draft might tend to limit 
what the other folks in the BOF want to do in the charter. It’s 
important to remember that most BOFs are held in order to get support 
for an eventual Working Group, not to get support for a particular 
document. 


Many BOFs don’t turn into WGs for a variety of reasons. A common 
problem is that not enough people can agree on a focus for the work. 
Another typical reason is that the work wouldn’t end up being a 
standard -- if, for example, the document authors don’t really want 
to relinquish change control to a WG. (We’11 discuss change control 
later in this document.) Only two meetings of a BOF can be scheduled 
on a particular subject; either a WG has to form or the topic should 
be dropped. 


7. New to the IETF and Coming to a Meeting? STOP HERE! (Temporarily) 


If you’re new to the IETF and this is the only reference you plan to 
read before coming to the meeting, stop here -- at least temporarily. 
Then, on your flight home, read the rest of the Tao. By that time 
you’ll be ready to get actively involved in the Working Groups that 
interested you at the meeting, and the Tao will get you started on 
your way. 


If you’re planning to participate in the IETF remotely, through 
reading email lists and the proceedings, read on! 
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8. 


RFCs and Internet Drafts 


If you’re a new IETF participant and are looking for a particular RFC 
or Internet Draft, go to the RFC Editor’s web pages, http://www.rfc- 
editor.org/rfc.html. That site also has links to other RFC 
collections, many with search capabilities. If you know the number 
of the RFC you’re looking for, go to the IETF RFC pages, 
http://www.ietf.org/rfc.html. For Internet Drafts, the best resource 
is the IETF web site, http://www.ietf.org/ID.html, where you can 
search by title and keyword. 


.1. Getting an RFC Published 


One of the most common questions seasoned IETFers hear from newcomers 
is, "How do I get an IETF standard published?" A much better 
question is, "Should I write an IETF standard?" since the answer is 
not always "yes." If you do decide to try to write a document that 
becomes an IETF standard, be warned that the overall process may be 
arduous, even if the individual steps are fairly straightforward. 
Lots of people get through the process unscathed, though, and there’s 
plenty of written guidance that helps authors emerge with their ego 
more or less intact. 


Every IETF standard is published as an RFC (a "Request for Comments," 
but everyone just calls them RFCs), and every RFC starts out as an 
Internet Draft (often called an "I-D"). The basic steps for getting 
something published as an IETF standard are as follows: 


1. Publish the document as an Internet Draft. 
2. Receive comments on the draft. 
3. Edit your draft based on the comments. 


4. Repeat steps 1 through 3 a few times. 


5. Ask an Area Director to take the draft to the IESG (if it’s an 
individual submission). If the draft is an official Working 
Group product, the WG chair asks the AD to take it to the IESG. 


6. Make any changes deemed necessary by the IESG (this might include 
giving up on becoming a standard). 


7. Wait for the document to be published by the RFC Editor. 
A much more complete explanation of these steps is contained in 


[BCP9], "The Internet Standards Process". Those who write drafts 
that they hope will become IETF standards must read BCP 9 so that 
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they can follow the path of their document through the process. BCP 
9 (and various other documents that update it) goes into great detail 
on a topic that is very often misunderstood, even by seasoned IETF 
participants: different types of RFCs go through different processes 
and have different rankings. There are six kinds of RFCs: 

o Proposed standards 

o Draft standards 

o Internet standards (sometimes called "full standards") 


o Informational documents 


o Experimental protocols 


o Historic documents 


Only the first three (proposed, draft, and full) are standards within 
the IETF. A good summary of this can be found in the aptly titled 
[RFC1796], "Not All RFCs Are Standards". 


There are also three sub-series of RFCs, known as FYIs, BCPs, and 
STDs. The For Your Information RFC sub-series was created to 
document overviews and topics that are introductory or that appeal to 
a broad audience; however, that series has not been added to ina 
long time. Best Current Practice documents describe the application 
of various technologies in the Internet. The STD RFC sub-series was 
created to identify RFCs that do in fact specify Internet standards. 
Some STDs are actually sets of more than one RFC, and the "standard" 
designation applies to the whole set of documents. 


8.2. Letting Go Gracefully 


The biggest reason some people do not want their documents put on the 
IETF standards track is that they must give up change control of the 
protocol. That is, as soon as you propose that your protocol become 
an IETF standard, you must fully relinquish control of the protocol. 
If there is general agreement, parts of the protocol can be 
completely changed, whole sections can be ripped out, new things can 
be added, and the name can be changed. 


Some authors find it very hard to give up control of their pet 
protocol. If you are one of those people, don’t even think about 
trying to get your protocol to become an IETF standard. On the other 
hand, if your goal is the best standard possible with the widest 
implementation, then you might find the IETF process to your liking. 
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Incidentally, the change control on Internet standards doesn’t end 
when the protocol is put on the standards track. The protocol itself 
can be changed later for a number of reasons, the most common of 
which is that implementors discover a problem as they implement the 
standard. These later changes are also under the control of the 
IETF, not the editors of the standards document. 


IETF standards exist so that people will use them to write Internet 


programs that interoperate. They don’t exist to document the 
(possibly wonderful) ideas of their authors, nor do they exist so 
that a company can say, "We have an IETF standard". If a standards- 


track RFC only has one implementation (whereas two are required for 
it to advance on the standards track), it was probably a mistake to 
put it on the standards track in the first place. 


8.3. Internet Drafts 


First things first. Every document that ends up in the RFC 
repository starts life as an Internet Draft. Internet Drafts are 
tentative documents -- they're meant for readers to comment on, so 
authors can mull over those comments and decide which ones to 
incorporate in the draft. In order to remind folks of their 
tentativeness, Internet Drafts are automatically removed from the 
online directories after six months. They are most definitely not 
standards or even specifications. As [BCP9] says: 


"An Internet Draft is NOT a means of 'publishing” a specification; 
specifications are published through the RFC mechanism.... Internet 
Drafts have no formal status, and are subject to change or removal at 
any time. Under no circumstances should an Internet Draft be 
referenced by any paper, report, or Request-for-Proposal, nor should 
a vendor claim compliance with an Internet Draft". 


You can always tell a person who doesn't understand the IETF (or is 
intentionally trying to fool people) when he or she brags about 
having published an Internet Draft; it takes no significant effort. 


When you submit an Internet Draft, you give some publication rights 
to the IETF. This is so that your Internet Draft is freely available 


to everyone who wants to read and comment on it. The rights you do 
and don’t give to the IETF are described in [BCP78], "IETF Rights in 
Contributions". 


There is a very useful checking tool at 
http://tools.ietf.org/tools/idnits/idnits.pyht. Using this tool 
before you turn in an Internet Draft will help prevent the draft from 
being rejected due to errors in form and formatting. 
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An I-D should have approximately the same format as an RFC. Contrary 
to many people’s beliefs, an I-D does not need to look exactly like 
an RFC, but if you can use the same formatting procedures used by the 
RFC Editor when you create your I-Ds, it will simplify the RFC 
Editor’s work when your draft is published as an RFC. [RFC2223], 
"Instructions to RFC Authors", describes the nroff formatting used by 
the RFC Editor. There is also a tool called "xml2rfc", available 
from http://xml.resource.org/, that takes XML-formatted text and 
turns it into a valid Internet Draft. 


An Internet Draft can be either a Working Group draft or an 
individual submission. Working Group drafts are usually reviewed by 
the Working Group before being accepted as a WG item, although the 
chairs have the final say. 


If you're interested in checking the status of a particular draft, or 
can’t remember its exact name, or want to find out which drafts a WG 
is working on, two handy tools are available. The "Internet Drafts 
Database Interface", at 
https://datatracker.ietf.org/public/idindex.cgi, lets you search for 
a draft by author, Working Group, date, or filename. The "I-D 
Tracker", at https://datatracker.ietf.org/public/pidtracker.cgi, is 
especially useful for authors who want to track the progress of their 
draft as it makes its way through the publication process. 


There are some informal rules for Internet Draft naming that have 


evolved over the years. Internet Drafts that revise existing RFCs 
often have draft names with "bis" in them, meaning "again" or 
"twice"; for example, a draft might be called "draft-someone- 


rfc2345bis-00.txt". 
8.3.1. Recommended Reading for Writers 


Before you create the first draft of your Internet Draft, you should 
read four documents: 


o More important than just explaining formatting, [RFC2223] also 
explains what needs to be in an Internet Draft before it can 
become an RFC. This document describes all the sections and 
notices that will need to be in your document, and it’s good to 
have them there from the beginning so that readers aren’t 
surprised when you put them in later versions. 


o [BCP22], "Guide for Internet Standards Writers", provides tips 
that will help you write a standard that leads to 
interoperability. For instance, it explains how to choose the 
right number of protocol options, how to respond to out-of-spec 
behavior, and how to show state diagrams. 
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o The online "Guidelines to Authors of Internet Drafts", 
http://www.ietf.org/ietf/lid-guidelines.txt, has up-to-date 
information about the process for turning in Internet Drafts, as 
well as the most current boilerplate information that has to be 
included in each Internet Draft. 


o When you think you are finished with the draft process and are 
ready to request that the draft become an RFC, you should 
definitely read "Checklist for Internet Drafts (I-Ds) Submitted 
for RFC Publication", http://www.ietf.org/ID-Checklist.html, a 
list of common issues that have been known to stop documents in 
the IESG. In fact, you should probably read that document well 
before you are finished, so that you don’t have to make a bunch of 
last-minute changes. 


Also, you should visit the IETF Tools web pages, 
http://tools.ietf.org, where you'11 find pointers to other tools that 
will automate some of your work for the IETF. 


8.3.2. Filenames and Other Matters 


When you’re ready to turn in your Internet Draft, send it to the 
Internet Drafts administrator at mailto:internet-—drafts@ietf.org. 
There is a real person at the other end of this mail address, whose 
job is to make sure you’ve included the minimum items you need for 
the Internet Draft to be published. When you submit the first 
version of the draft, you also tell the draft administrator your 
proposed filename for the draft. If the draft is an official Working 
Group product, the name will start with "draft-ietf-" followed by the 
designation of the WG, followed by a descriptive word or two, 
followed by "00.txt". 


For example, a draft in the S/MIME WG about creating keys might be 
named "draft-ietf-smime-keying-00.txt". If it’s not the product of a 
Working Group, the name will start with "draft-" and the last name of 
one of the authors followed by a descriptive word or two, followed by 
"00.txt". For example, a draft that someone named Smith wrote might 
be named "draft-smith-keying-00.txt". If a draft is an individual 
submission but relates to a particular Working Group, authors 
sometimes follow their name with the name of the Working Group, such 
as "draft-smith-smime-keying-00.txt". You are welcome to suggest 
names; however, it is up to the Internet Drafts administrator (and, 
if it is an official WG draft, the WG chair) to come up with the 
filename. If you follow the naming guidelines given at 
http://www.ietf.org/ietf/lid-guidelines.txt, chances are quite good 
that your suggested filename will be fine. 
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After the first edition of a draft, the number in the filename is 
incremented; for instance, the second edition of the S/MIME draft 
named above would be "draft-ietf-smime-keying-01.txt". Note that 
there are cases where the filename changes after one or more 
versions, such as when a personal effort is pulled into a Working 
Group; when a draft has its filename changed, the number reverts to 
-00. Be sure to let the Internet Drafts administrator know the 
previous name of the draft when such a name change occurs so that the 
databases can be kept accurate. 


8.4. Standards-Track RFCs 


The procedure for creating and advancing a standard is described in 
[BCP9]. After an Internet Draft has been sufficiently discussed and 
there is rough consensus that what it says would be a useful 
standard, it is presented to the IESG for consideration. If the 
draft is an official WG draft, the WG chair sends it to the 
appropriate Area Director after it has gone through Working Group 
last call. If the draft is an individual submission, the draft’s 
author or editor submits it to the appropriate Area Director. BCP 9 
also describes the appeals process for people who feel that a Working 
Group chair, an AD, or the IESG has made the wrong decision in 
considering the creation or advancement of a standard. 


After the I-D is submitted to the IESG, the IESG announces an IETF- 
wide last call. This helps get the attention of people who weren’t 
following the progress of the draft, and it can sometimes cause 
further changes to the draft. It is also a time when people in the 
WG who feel that they weren’t heard can make their comments to 
everyone. The IETF last call is two weeks for drafts coming from WGs 
and four weeks for individual submissions. 


If the IESG approves the draft to become an Internet standard, they 
ask the RFC Editor to publish it as a Proposed standard. After it 
has been a Proposed standard for at least six months, the RFC’s 
author (or the appropriate WG chair) can ask for it to become a Draft 
standard. Before that happens, however, someone needs to convince 
the appropriate Area Director that there are at least two 
independent, interoperable implementations of each part of the 
standard. This is a good test of the usefulness of the standard as a 
whole, as well as an excellent way to check if the standard was 
really readable. 


A few things typically happen at this point. First, it’s common to 
find that some of the specifications in the standard need to be 
reworded because one implementor thought they meant one thing whereas 
another implementor thought they meant something else. Another 
common occurrence is that none of the implementations actually tried 
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to implement a few of the features of the standard; these features 
get removed not just because no one tested them but also because they 
weren’t needed. 


Don’t be surprised if a particular standard doesn’t progress from 
Proposed to Draft. In fact, most of the standards in common use are 
Proposed standards and never move forward. This may be because no 
one took the time to try to get them to Draft, or some of the 
normative references in the standard are still at Proposed standard, 
or it may be that everyone found more important things to do. 


A few years after a document has been a Draft standard, it can become 
an Internet standard, also known as "full standard" (it can happen in 
as little as four months, but this is rare). This doesn’t happen 
often, and it is usually reserved for protocols that are absolutely 
required for the Internet to function. The IESG goes over the 
document with a fine-tooth comb and looks for evidence of widespread 
deployment before making a Draft standard an Internet standard. 


8.4.1. Telling It Like It Is -- Using MUST and SHOULD and MAY 


Writing specifications that get implemented the way you want is a bit 
of an art. You can keep the specification very short, with just a 
list of requirements, but that tends to cause implementors to take 
too much leeway. If you instead make the specification very wordy 
with lots of suggestions, implementors tend to miss the requirements 
(and often disagree with your suggestions anyway). An optimal 
specification is somewhere in between. 


One way to make it more likely that developers will create 
interoperable implementations of standards is to be clear about 
what’s being mandated in a specification. Early RFCs used all kinds 
of expressions to explain what was needed, so implementors didn’t 
always know which parts were suggestions and which were requirements. 
As a result, standards writers in the IETF generally agreed to limit 
their wording to a few specific words with a few specific meanings. 


[STD3], "Requirements for Internet Hosts -- Application and Support", 
written way back in 1989, had a short list of words that had appeared 
to be useful, namely, "must", "should", and "may". These definitions 


were updated and further refined in [BCP14], "Key words for use in 
RFCs to Indicate Requirement Levels", which is widely referenced in 


current Internet standards. BCP 14 also specifically defines "must 
not" and "should not", and it lists a few synonyms for the words 
defined. 
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In a standard, in order to make it clear that you’re using the 
definitions from BCP 14, you should do two things. First, refer to 
BCP 14 (although most people refer to it as RFC 2119, because that’s 
what BCP 14 tells you to do), so that the reader knows how you’re 
defining your words. Second, you should point out which instances of 
the words you are using come from BCP 14. The accepted practice for 
this is to capitalize the words. That is why you see "MUST" and 
"SHOULD" capitalized in IETF standards. 


BCP 14 is a short document, and it should be read by everyone who is 
reading or writing IETF standards. Although the definitions of 
"must" and "must not" are fairly clear, the definitions of "should" 
and "should not" cause a great deal of discussion in many WGs. When 
reviewing an Internet Draft, the question is often raised, "Should 
that sentence have a MUST or a SHOULD in it?" This is, indeed, a 
very good question, because specifications shouldn't have gratuitous 
MUSTs, but also should not have SHOULDs where a MUST is needed for 
interoperability. This goes to the crux of the question of over- 
specifying and under-specifying requirements in standards. 


8.4.2. Normative References in Standards 


One aspect of writing IETF standards that trips up many novices (and 
quite a few long-time IETF folks) is the rule about how to make 
"normative references" to non-IETF documents or to other RFCs ina 
standard. A normative reference is a reference to a document that 
must be followed in order to implement the standard. A non-normative 
reference (sometimes called an "informative reference") is one that 
is helpful to an implementor but is not needed. 


An IETF standard may make a normative reference to any other 
standards-track RFC that is at the same standards level or higher, or 
to any "open standard" that has been developed outside the IETF. The 
"same level or higher" rule means that before a standard can move 
from Proposed to Draft, all of the RFCs for which there is a 
normative reference must also be at Draft or Internet standard. This 
rule gives implementors assurance that everything in a Draft standard 
or Internet standard is quite stable, even the things referenced 
outside the standard. This can also delay the publication of the 
Draft or Internet standard by many months (sometimes even years) 
while the other documents catch up. 


There is no hard-and-fast rule about what is an "open standard", but 
generally this means a stable standard that anyone can get a copy of 
(although they might have to pay for it) and that was made by a 
generally recognized standards group. If the external standard 
changes, you have to reference the particular instantiation of that 
standard in your specification, as with a designation of the date of 


Hoffman & Harris Informational [Page 36] 


RFC 4677 The Tao of IETF September 2006 


the standard. Some external standards bodies don’t make old 
standards available, which is a problem for IETF standards that need 
to be used in the future. When in doubt, a draft author should ask 
the WG chair or appropriate Area Director if a particular external 
standard can be used in an IETF standard. 


8.4.3. IANA Considerations 


More and more IETF standards require the registration of various 
protocol parameters, such as named options in the protocol. As we 
noted in Section 3.2.4, the main registry for all IETF standards has 
long been IANA. Because of the large and diverse kinds of registries 
that standards require, IANA needs to have specific information about 
how to register parameters, what not to register, who (if anyone) 
will decide what is to be registered, and so on. 


Anyone writing an Internet standard that may need a new IANA registry 
or new values in a current IANA registry needs to read [BCP26], 
"Guidelines for Writing an IANA Considerations Section in RFCs", 
which describes how RFC authors should properly ask for IANA to start 
or take over a registry. IANA also maintains registries that were 
started long before BCP 26 was produced. 


8.4.4. Security Considerations 


One thing that’s required in every RFC and Internet Draft is a 
"Security Considerations" section. This section should describe any 
known vulnerabilities of the protocol, possible threats, and 
mechanisms or strategies to address them. Don’t gloss over this 
section -- in particular, don’t say, "Here's our protocol, if you 
want security, just use IPsec". This won’t do at all, because it 
doesn’t answer the question of how IPsec interacts with your 
protocol, and vice versa. Be sure to check with your Working Group 
chair if you’re not sure how to handle this section in your draft. 
See [BCP72], "Guidelines for Writing RFC Text on Security 
Considerations", for more information on writing good security 
considerations sections. 


8.4.5. Patents in IETF Standards 


The problems of intellectual property have cropped up more and more 
often in the past few years, particularly with respect to patents. 
The goal of the IETF is to have its standards widely used and 
validated in the marketplace. If creating a product that uses a 
standard requires getting a license for a patent, people are less 
likely to implement the standard. Not surprisingly, then, the 
general rule has been "use good non-patented technology where 
possible". 
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Of course, this isn’t always possible. Sometimes patents appear 
after a standard has been established. Sometimes there’s a patent on 
something that is so valuable that there isn’t a non-patented 
equivalent. Sometimes the patent holder is generous and promises to 
give all implementors of a standard a royalty-free license to the 
patent, thereby making it almost as easy to implement as it would 
have been if no patent existed. 


The IETF’s methods for dealing with patents in standards are a 
subject of much debate. The official rules for all intellectual 
property rights (IRP) in IETF documents (not just patents) are 
covered in [BCP78] and [BCP79], "Intellectual Property Rights in IETF 
Technology". Everyone who participates in IETF Working Groups will 
probably find these documents interesting because they lay out the 
rules that everyone agrees to follow. 


Patent holders who freely allow their patents to be used by people 
implementing IETF standards often get a great deal of goodwill from 
the folks in the IETF. Such generosity is more common than you might 
think. For example, RFC 1822 is a license from IBM for one of its 
security patents, and the security community has responded very 
favorably to IBM for this (whereas a number of other companies have 
made themselves pariahs for their intractability on their security 
patents). 


If you are writing an Internet Draft and you know of a patent that 
applies to the technology you’re writing about, don’t list the patent 
in the document. Instead, consult the IETF IPR Disclosure Page 
linked off the main IETF web site to determine how to proceed. 
Intellectual property rights aren’t mentioned in RFCs because RFCs 
never change after they are published, but knowledge of IPR can 
change at any time. Therefore, an IPR list in an RFC could be 
incomplete and mislead the reader. [BCP9] provides specific text 
that should be added to RFCs where the author knows of IPR issues. 


8.5. Informational and Experimental RFCs 


As we noted earlier, not all RFCs are standards. In fact, plenty of 
important RFCs are not on the standards track at all. Currently, 
there are two designations for RFCs that are not meant to be 
standards: Informational, like the Tao, and Experimental. (There is 
actually a third designation, Historic, but that is reserved for 
documents that were on the standards track and have been removed due 
to lack of current use, or that more recent thinking indicates the 
technology is actually harmful to the Internet.) 
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9. 


9. 


The role of Informational RFCs is often debated in the IETF. Many 
people like having them, particularly for specifications that were 
created outside the IETF but are referenced by IETF documents. They 
are also useful for specifications that are the precursors for work 
being done by IETF Working Groups. On the other hand, some people 
refer to Informational RFCs as "standards" even though the RFCs are 
not standards, usually to fool the gullible public about something 
that the person is selling or supporting. When this happens, the 
debate about Informational RFCs is renewed. 


Experimental RFCs are for specifications that may be interesting, but 
for which it is unclear if there will be much interest in 
implementing them, or whether they will work once deployed. That is, 
a specification might solve a problem, but if it is not clear that 
many people think that the problem is important, or think that they 
will bother fixing the problem with the specification, the 
specification might be labeled an Experimental RFC. If, later, the 
specification becomes popular (or proves that it works well), it can 
be re-issued as a standards-track RFC. Experimental RFCs are also 
used to get people to experiment with a technology that looks like it 
might be standards-track material, but for which there are still 
unanswered questions. 


The IESG has created guidelines on how it chooses between 
Informational and Experimental status: 
http://www.ietf.org/u/ietfchair/info-exp.html. If you are creating a 
document that you think might become an Experimental RFC, knowing the 
current thinking will help you justify your proposed choice. 


How to Contribute to the IETF 
1. What You Can Do 


*Read* -- Review the Internet Drafts in your area of expertise and 
comment on them in the Working Groups. Participate in the discussion 
in a friendly, helpful fashion, with the goal being the best Internet 
standards possible. Listen much more than you speak. If you 
disagree, debate the technical issues: never attack the people. 


*Implement* -- Write programs that use the current Internet 
standards. The standards aren’t worth much unless they are available 
to Internet users. Implement even the "minor" standards, since they 
will become less minor if they appear in more software. Report any 
problems you find with the standards to the appropriate Working Group 
so that the standard can be clarified in later revisions. One of the 
oft-quoted tenets of the IETF is "running code wins", so you can help 
support the standards you want to become more widespread by creating 
more running code. 
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*Write* -- Edit or co-author Internet Drafts in your area of 
expertise. Do this for the benefit of the Internet community, not to 
get your name (or, even worse, your company’s name) on a document. 
Draft authors are subject to all kinds of technical (and sometimes 
personal) criticism; receive it with equanimity and use it to improve 
your draft in order to produce the best and most interoperable 
standard. 


9.2. What Your Company Can Do 


*Share* -- Avoid proprietary standards. If you are an implementor, 
exhibit a strong preference for IETF standards. If the IETF 
standards aren’t as good as the proprietary standards, work to make 
the IETF standards better. If you’re a purchaser, avoid products 
that use proprietary standards that compete with the open standards 
of the IETF and tell the companies you buy from that you are doing 
so. 


*Open Up* -- If your company controls a patent that is used in an 
IETF standard, convince the company to make the patent available at 
no cost to everyone who is implementing the standard. In the past 
few years, patents have caused a lot of serious problems for Internet 
standards because they prevent some companies from being able to 
freely implement the standards. Fortunately, many companies have 
generously offered unlimited licenses for particular patents in order 
to help the IETF standards flourish. These companies are usually 
rewarded with positive publicity for the fact that they are not as 
greedy or short-sighted as other patent-holders. 


*Join* -- Become a member of ISOC. More important, urge any company 
that has benefited from the Internet to become a corporate member of 
ISOC, since this has the greatest financial benefit for the group. 
It will, of course, also benefit the Internet as a whole. 


10. IETF and the Outside World 
10.1. IETF and Other Standards Groups 


As much as many IETF participants would like to think otherwise, the 
IETF does not exist in a standards vacuum. There are many (perhaps 
too many) other standards organizations whose decisions affect the 
Internet. There are also a fair number of standards bodies that 
ignored the Internet for a long time and now want to get a piece of 
the action. 


In general, the IETF tries to have cordial relationships with other 


Significant standards bodies. This isn’t always easy, since many 
other bodies have very different structures than the IETF does, and 
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the IETF is mostly run by volunteers who would probably prefer to 
write standards rather than meet with representatives from other 
bodies. Even so, some other standards bodies make a great effort to 
interact well with the IETF despite the obvious cultural differences. 


At the time of this writing, the IETF has some liaisons with large 
standards bodies, including the ITU (International Telecommunication 
Union), the W3C, the Unicode Consortium, and ISO/IEC JTC1 (Joint 
Technical Committee of the International Organization for 
Standardization and International Electrotechnical Commission). As 
stated in the IAB Charter [BCP39], "Liaisons are kept as informal as 
possible and must be of demonstrable value in improving the quality 
of IETF specifications". In practice, the IETF prefers liaisons to 
take place directly at Working Group level, with formal relationships 
and liaison documents in a backup role. 


Some of these liaison tasks fall to the IESG, whereas others fall to 
the IAB. Detail-oriented readers will learn much about the formal 
methods for dealing with other standards bodies in [BCP102], "IAB 
Processes for Management of IETF Liaison Relationships", and 
[BCP103], "Procedures for Handling Liaison Statements to and from the 
IETF". The best place to check to see whether the IETF has any 
formal liaison at all is the list of IETF liaisons, 
www.ietf.org/liaisonActivities.html. The list shows that there are 
many different liaisons to ISO/IEC JTC1 subcommittees. 


.2. Press Coverage of the IETF 


Given that the IETF is one of the best-known bodies that is helping 
move the Internet forward, it’s natural for the computer press (and 


even the trade press) to want to cover its actions. In recent years, 
a small number of magazines have assigned reporters and editors to 
cover the IETF in depth over a long period of time. These reporters 


have ample scars from articles that they got wrong, incorrect 
statements about the status of Internet Drafts, quotes from people 
who are unrelated to the IETF work, and so on. 


Major press errors fall into two categories: saying that the IETF is 
considering something when in fact there is just an Internet Draft in 
a Working Group, and saying that the IETF approved something when all 
that happened was that an Informational RFC was published. In both 
cases, the press is not fully to blame for the problem, since they 
are usually alerted to the story by a company trying to get publicity 
for a protocol that they developed or at least support. Of course, a 
bit of research by the reporters would probably get them in contact 
with someone who could straighten them out, such as a WG chair or an 
Area Director. The default press contact for the IETF is the IAD, 
who can be reached at mailto:iad@ietf.org. 
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The fact that those reporters who’ve gotten it wrong once still come 
back to IETF meetings shows that it is possible to get it right 
eventually. However, IETF meetings are definitely not for reporters 
who are naive about the IETF process (although if you are a reporter 
the fact that you are reading this document is a very good sign!). 
Furthermore, if you think that you'll get a hot story from attending 
an IETF meeting, you are likely to be disappointed. 


Considering all this, it’s not surprising that some IETFers would 
prefer to have the press stay as far away from meetings as possible. 
Having a bit of press publicity for protocols that are almost near 
completion and will become significant in the industry in the next 
year can be a good thing. However, it is the rare reporter who can 
resist over-hyping a nascent protocol as the next savior for the 
Internet. Such stories do much more harm than good, both for the 
readers of the article and for the IETF. 


The main reason why a reporter might want to attend an IETF meeting 
is not to cover hot technologies (since that can be done in the 
comfort of your office by reading the mailing lists) but to meet 
people face-to-face. Unfortunately, the most interesting people are 
the ones who are also the busiest during the IETF meeting, and some 
folks have a tendency to run away when they see a press badge. 
However, IETF meetings are excellent places to meet and speak with 
document authors and Working Group chairs; this can be quite valuable 
for reporters who are covering the progress of protocols. 


Reporters who want to find out about "what the IETF is doing" on a 
particular topic would be well-advised to talk to more than one 
person who is active on that topic in the IETF, and should probably 
try to talk to the WG chair in any case. It’s impossible to 
determine what will happen with a draft by looking at the draft or 
talking to the draft’s author. Fortunately, all WGs have archives 
that a reporter can look through for recent indications about what 
the progress of a draft is; unfortunately, few reporters have the 
time or inclination to do this kind of research. Because the IETF 
doesn’t have a press liaison, magazines or newspapers that run a 
story with errors won’t hear directly from the IETF and therefore 
often won’t know what they did wrong, so they might easily do it 
again later. 


11. Security Considerations 


Section 8.4.4 explains why each RFC is required to have a Security 
Considerations section and gives some idea of what it should and 
should not contain. Other than that information, this document does 
not touch on Internet security. 
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Appendix A. Related Information 
A.1. Why "the Tao"? 


Pronounced "dow", Tao is the basic principle behind the teachings of 
Lao-tse, a Chinese master. Its familiar symbol is the black-and- 
white yin-yang circle. Taoism conceives the universe as a single 
organism, and human beings as interdependent parts of a cosmic whole. 
Tao is sometimes translated "the way", but according to Taoist 
philosophy the true meaning of the word cannot be expressed in words. 


A.2. Useful Email Addresses 
Some useful email addresses are listed here. These addresses may 


change from time to time, and it’s a good idea to check the IETF web 
pages for the correct address before sending your mail. 


Address Description 

agenda@ietf.org Requests for agenda slots at IETF 
meetings 

ietf-action@ietf.org Requests for things to be done when you 
don’t know exactly where to send the 
request 

ietf-info@ietf.org General questions about the IETF 

ietf-registrar@ietf.org Questions about registration, meeting 


locations, and fees 


ietf-request@ietf.org Requests to join/leave IETF lists 

ietf-secretary@ietf.org Questions for the Secretariat 

ietf-web@ietf.org Questions or comments about the IETF 
web site 

internet—drafts@ietf.org Internet Draft submissions and queries 

proceedings@ietf.org Where to send Working Group minutes and 


slides for the IETF Proceedings 
iana@iana.org Internet Assigned Numbers Authority 


rfc-editor@rfc-editor.org RFC Editor 
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statements@ietf.org Incoming liaison statements from other 
organizations 


Online upload pages are planned for the future to facilitate 
submission of Internet Drafts, Proceedings, and Liaison statements. 


A.3. Useful Documents and Files 


The IETF web site, http://www.ietf.org, is the best source for 
information about meetings, Working Groups, Internet Drafts, RFCs, 
IETF email addresses, and much more. Click on "Additional 
Information" to find a variety of helpful links. Internet Drafts and 
other documents are also available in the "ietf" directory on 
anonymous FTP sites worldwide. For a listing of these sites, see 
http://www.ietf.org/shadow.html. 


Check the IESG web pages, http://www.ietf.org/iesg.html, to find up- 
to-date information about drafts processed, RFCs published, and 
documents in Last Call, as well as the monthly IETF status reports. 


A.4. Acronyms and Abbreviations Used in the Tao 


Some of the acronyms and abbreviations from this document are listed 


below. 

Term Meaning 

AD Area Director 

BCP Best Current Practice 

BOF Birds of a Feather 

FAQ Frequently Asked Question(s) 

FYI For Your Information (RFC) 

TAB Internet Architecture Board 

TAD IETF Administrative Director 

TANA Internet Assigned Numbers Authority 

TAOC IETF Administrative Oversight Committee 

IASA IETF Administrative Support Activity 

ICANN Internet Corporation for Assigned Names and 
Numbers, http://www.icann.org/ 

I-D Internet Draft 

IESG Internet Engineering Steering Group, 
http://www.ietf.org/iesg.html 

IETF Internet Engineering Task Force, 

http://www.ietf.org/ 

INET Internet Society Conference, 
http://www.isoc.org/isoc/conferences/inet/ 

IPR Intellectual property rights 

IRTF Internet Research Task Force, http://www.irtf.org/ 
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International Organization for Standardization, 
http: //www.iso.ch/ 


ISO-IEC/JTC1 Joint Technical Committee of the International 


ISOC 


ITU 


RFC 
STD 
W3C 
WG 


Organization for Standardization and 
International Electrotechnical Commission, 
http://www. jtcl.org/ 

Internet Society, http://www.isoc.org 

International Telecommunication Union, 
http://www.itu.int 

Request for Comments 

Standard (RFC) 

World Wide Web Consortium, http://www.w3.org/ 

Working Group 


Appendix B. IETF Guiding Principles 


If you’ve gotten this far in the Tao, you’ve learned a lot about how 
the IETF works. What you'll find in this appendix summarizes much of 
what you’ve read and adds a few new points to ponder. Be sure to 
read through all the principles; taken as a whole, they’1l give you a 
new slant on what makes the IETF work. 


B.1. 


Pl. 


B2 


Bais 


P4. 


PS. 


P6. 


General 


The IETF works by an open process and by rough consensus. This 
applies to all aspects of the operation of the IETF, including 
creation of IETF documents and decisions on the processes that 
are used. But the IETF also observes experiments and running 
code with interest, and this should also apply to the 
operational processes of the organization. 


The IETF works in areas where it has, or can find, technical 
competence. 


The IETF depends on a volunteer core of active participants. 
Membership of the IETF or of its WGs is not fee-based or 


organizationally defined, but is based upon self-identification 
and active participation by individuals. 


Management and Leadership 


The IETF recognizes leadership positions and grants power of 
decision to the leaders, but decisions are subject to appeal. 


Delegation of power and responsibility are essential to the 
effective working of the IETF. As many individuals as possible 
will be encouraged to take on leadership of IETF tasks. 
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P9. 


P10. 
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Dissent, complaint, and appeal are a consequence of the IETF’s 
nature and should be regarded as normal events, but ultimately 
it is a fact of life that certain decisions cannot be 
effectively appealed. 


Leadership positions are for fixed terms (although we have no 
formal limitation on the number of terms that may be served). 


It is important to develop future leaders within the active 
community. 


A community process is used to select the leadership. 


Leaders are empowered to make the judgment that rough 
consensus has been demonstrated. Without formal membership, 
there are no formal rules for consensus. 


B.3. Process 


PIZ. 


P13. 


P14. 


Although the IETF needs clear and publicly documented process 
rules for the normal cases, there should be enough flexibility 
to allow unusual cases to be handled according to common sense. 
We apply personal judgment and only codify when we’re certain. 
(But we do codify who can make personal judgments.) 


Technical development work should be carried out by tightly 
chartered and focused Working Groups. 


Parts of the process that have proved impractical should be 
removed or made optional. 


B.4. Working Groups 


Pld 


P16. 


P17. 


Working Groups (WGs) should be primarily responsible for the 
quality of their output, and therefore for obtaining early 
review; WG chairs as WG leaders, backed up by the IETF 
leadership, should act as a quality backstop. 


WGs should be primarily responsible for assessing the negative 
impact of their work on the Internet as a whole, and therefore 
for obtaining cross-area review; the IETF leadership should act 
as a cross-area backstop. 


Early review of documents is more effective in dealing with 
major problems than late review. 
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Area Directors (ADs) are responsible for guiding the formation 
and chartering of WGs, for giving them direction as necessary, 
and for terminating them. 


WG chairs are responsible for ensuring that WGs execute their 
charters, meet their milestones, and produce deliverables that 
are ready for publication. 


ADs are responsible for arranging backstop review and final 
document approval. 


B.5. Documents 


P21. 


P22. 


P23. 


P24. 


P25. 


P26. 


P27. 


P28. 


P29. 


IETF documents often start as personal drafts, may become WG 
drafts, and are approved for permanent publication by a 
leadership body independent of the WG or individuals that 
produced them. 


IETF documents belong to the community, not to their authors. 
But authorship is recognized and valued, as are lesser 
contributions than full authorship. 


Technical quality and correctness are the primary criteria for 
reaching consensus about documents. 


IETF specifications may be published as Informational, 
Experimental, Standards Track, or Best Current Practice. 


IETF Standards Track specifications are not considered to be 
satisfactory standards until interoperable independent 
implementations have been demonstrated. (This is the 
embodiment of the "running code" slogan.) But, on legal 
advice, the IETF does not take responsibility for 
interoperability tests and does not certify interoperability. 


IETF processes are currently published as Best Current Practice 
documents. 


Useful information that is neither a specification nor a 
process may be published as Informational. 


Obsolete or deprecated specifications and processes may be 
downgraded to Historic. 


The standards track should distinguish specifications that have 
been demonstrated to interoperate. 
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P30. Standards Track and Best Current Practice documents must be 
subject to IETF wide rough consensus (Last Call process). WG 


rough consensus is normally sufficient for other documents. 


P31. Substantive changes made after a document leaves a WG must be 
referred back to the WG. 


P32. The IETF determines requirements for publication and archiving 
of its documents. 
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